A programmable logic device (PLD) is an electronic component used to build reconfigurable digital circuits. Unlike a logic gate, which has a fixed function, a PLD has an undefined function at the time of manufacture. Before the PLD can be used in a circuit, it must be programmed (i.e. reconfigured). PLDs are typically, but certainly not exclusively, used in application simultaneously requiring a logic device and a memory device; such as in reconfigurable computing systems, distributed gateway architectures, and the like.
Normally PLDs are configured and/or reprogrammed in the field using allocated dedicated I/O pins and wires specifically for this task. Styles of reprogramming via allocated I/O pins are described in—U.S. Pat. No. 5,764,076: Circuit for partially reprogramming an operational programmable logic device; U.S. Pat. No. 7,265,578: In-system programming of non-JTAG device using SPI and JTAG interfaces; U.S. Pat. No. 6,459,297: System for programming field programmable devices; U.S. Pat. No. 7,248,070: Method and system for using boundary scan in a programmable logic device.
For the sake of good order, it is noted that a “JTAG” in our context is a “PLD JTAG programming interface”. Joint Test Action Group (JTAG) is the usual name used for the IEEE 1149.1 standard entitled Standard Test Access Port and Boundary-Scan Architecture. The JTAG interface allows hardware to transfer data (signals) into internal non-volatile device memory; for programming as well as testing and debugging the device. A JTAG interface is a special (at least) four/five-pin interface connector on a chip or a board, wherein the connector pins are TDI (Test Data In), TDO (Test Data Out), TCK (Test Clock), TMS (Test Mode Select), and optional TRST (Test Reset—used by some devices to apply reset to the device). JTAG interfaces are typically used in PLDs, field-programmable gate arrays, complex programmable logic device, CPU's, controllers and the like.
Recent developments in PLD's have made it possible to re-program a PLD using a JTAG interface, while the PLD is operating as previously programmed, without the re-programming process interrupting the PLD's normal operation. This can be better understood in conjunction with a careful study of FIG. 1, showing a scheme suitable for field programming a PLD (e.g. 110) or a multitude of PLDs (110, 120). In a PLD programming controller (112), instructions received serially through a JTAG interface block (111) are translated into specific PLD instructions; a Non-Volatile Memory (NVRAM) (113) is loaded with those instructions, forming the required new program; and on power-up or on a dedicated reset signal, the content of the NVRAM is transferred over to a SRAM (114)—wherein the SRAM (114) is responsible for the configuration of the PLD (110). It should be understood that the SRAM content is not affected during the process of loading the new program into the NVRAM (113), meaning that the re-programming process does not alter the normal operation of the PLD (110). It should further be understood that SRAM may be employed in various embodiments including SRAM block internal to the PLD, distributed memory cells, memory attached to the PLD logic cells and the like.
It should however be noted, that with prior art PLD's, employed in prior art architectures, addressing a multitude of PLDs serially, along a JTAG chain, manifests a great disadvantage. Such a serial architecture requires the completeness of the JTAG chain, hence it is severely sensitive to any instance of removing an element thereof or disenfranchising post-failure PLDs from the system. There is thus a longstanding need in the PLD arts for instantiation which will allow greater flexibility and robustness to adding or removing PLD's from the system, and in particular to such disenfranchising post-failure PLDs.
In the system described in FIG. 1, the PLDs (110, 120) can be programmed either by a JTAG programmer (not shown) connected to a JTAG connector (150), or by the CPU (160). In practice, the JTAG connector (150) may be used for serially programming or testing the PLDs (110, 120) present in the respective JTAG chain, while the CPU (160) may be used for programming the PLDs individually. In order to provide a solution which allows programming of any PLD (e.g. 110) in the distributed system, a multiplexer (MUX) (117, 127) is associated with each PLD. The MUX is designed to allow the CPU direct access to the JTAG (programming) interface of the target PLD upon a proper “select” signal. The PLD to be programmed is selected through the CPU field-programming interface, according to the unique MUX Select line (161, 162) which is being selected.
A set of dedicated programming wires (165) (duplications of the four typical JTAG wires) and control signals are driven by the CPU toward the distributed PLDs. The CPU uses the control signals to activate the multiplexer elements along the way and near the PLDs so that these dynamically route the data on the programming wires to the selected one-of-many target PLDs, requiring reprogramming. In the default case no select line (161, 162) is activated and all MUX elements direct towards the PLDs (110, 120) the programming wires and control signals (155) driven by the JTAG connector, thus enabling in the default case serial programming by the JTAG connector (150). It should be noted that in this solution for field programming PLDs, the complexity of the wiring increases with the number of PLDs to be programmed. This poses a severe penalty on systems including a multitude of PLDs, and moreover, serious difficulty in designing distributed systems which are scalable, namely including a changeable number of units and in particular a changeable number of PLDs.
Thus, there remains a need for JTAG-interfaced, field programmable PLDs, specifically in distributed systems comprising a multitude of such PLDs. Furthermore, there is a need for a solution that, while employing a JTAG interface for re-programming the PLDs, would circumvent the inherent serial nature of the architecture associated with the JTAG chain. Thus, PLDs field programming solution is needed, that allows accessing and programming any single PLD independently of other PLDs in the system, and irrespectively of previous or later accessing and programming such PLDs. Moreover, there is need for a solution that thus enables addressing and programming any single PLD as described above, in a distributed and scaleable system, without scarifying the complexity of the system and its wiring.
Alternately stated, in a system requiring firmware updates to PLDs, dedicated signals and wire resources presently have to be allocated. These signals carry the PLD firmware data-signal stream. In a system having multiple PLDs, and on the other hand, limited wire resources, there would be economic benefits to using PLDs with minimal additional wires.
Even though less allocated pins on the PLD itself might represent an aspect of progress, a PLD requiring more IOs (e.g. implementing a data transfer “shunt”) but saving on overall system distributed wires (logic/complexity) would be of greater benefit.